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La presente invention concerne les systemes 
d'echanges de messages entre serveur d' application et 
cartes a puce empruntant un reseau de communication. 
Elle s' applique aux echanges s'effectuant a travers les 
reseaux de telecommunication, reseau telephonique 
commute, reseau cellulaire ou reseau Internet. , 

Generalement, les messages echanges entre un 
serveur d' application et 1' application correspondante 
dans une carte a puce transitent par un equipement 
intermediate que l'on designera par terminal dans la 
suite. La carte a puce d'un utilisateur coopere avec le 
terminal pour permettre les echanges. 

Dans le cas ou le reseau emprunte est un reseau de 
telephonie, le terminal est un terminal de 
15 telecommunication. Dans le cas ou le reseau emprunte 
est un reseau inf ormatique, le terminal est un 
equipement inf ormatique de type ordinateur equipe d'une 
interface de lecture/ ecriture de cartes a puce. 

Un serveur sous controle d'un organisme emetteur de 
20 carte, desirant effectuer une action securisee dans une 
carte a puce (ou dans une application de ladite carte) 
via un reseau telephonique, utilise des certificats 
cryptographique permettant d' assurer la securite des 
echanges . 

25 Cependant, en cas de perte d'un message durant la 

transmission ou 1' execution ou en cas de tentative de 
fraude, la re-synchronisation des messages serveur- 
cartes peut poser des problemes securitaires. 

Dans le cas ou le terminal est un terminal dedie et 
securise sous contrSle de 1' organisme emetteur (par 
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exemple un distributeur automatique de billets DAB sous 
controle d'une banque) , la perte d'un message est 
compensee par des mecanismes de synchronisation mettant 
en jeu a la fois le logiciel du serveur et le logiciel 
du terminal dedie. Le terminal dedie est securise soit 
physiquement (DAB) soit contient a 1'interieur un 
module SAM (Secure Authentication Module) , et dans tous 
les cas est controle etroitement par 1'organisme 
emetteur . 

Si le terminal utilise n'est pas un terminal dedie 
et securise (par exemple telephone GSM, PC sous 
internet,...), les mecanismes de synchronisation ne 
peuvent pas etre bases sur la securite du terminal, du 
fait que celui-ci n'est pas controlable par 1' emetteur. 
15 En effet, il est important de pouvoir re- 

synchroniser la source des messages et la carte a puce 
en cas de probleme de transmission sur le reseau. Ce 
probleme a ete pose en terme de securite vis-a-vis des 
operateurs et des fournisseurs de service. 

II n'existe pas a ce jour de systeme prevu pour 
assurer une synchronisation entre la carte et le 
serveur, dans les cas ou pendant une transaction en 
cours, acceptee par consequent par la carte, le serveur 
profite de la connexion pour envoyer un message 
comportant une ou plusieurs actions a mettre en oeuvre 
par la carte, ces actions pouvant etre par exemple un 
rechargement d'unites de valeur ou de parametres 
(monetaires ou autre) ou un chargement d'une nouvelle 
application . 

En effet, il est prevu dans le cadre plus general 
des cartes multi-applicatives , que des message soient 
envoyes alors que 1'utilisateur a fait une demande de 
transaction afin d' envoyer des commandes pour des 
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actions a entreprendre pendant le deroulement de 
l'application pour la transaction en cours. 

De tels messages permettront par exemple de 
commander un rechargement de porte-monnaie electronique 
dans le cas d'une application porte-monnaie 
electronique, ou de modifier des parametres bancaires 
de l'application bancaire, ou le chargement d'une 
nouvelle application dans la carte. 

II est clair que dans cette situation, le serveur 
ne sera pas informe dans le cas ou ledit message est 
perdu. 

En d'autres termes, effectuer des actions 
securisees sur un terminal non dedie est faisable 
aujourd'hui mais impose, soit des contraintes 
utilisateur fortes (cartes ou applications bloquees si 
1' action securitaire n'est pas parvenue a terme) , soit 
des risques de perte d' informations (par exemple perte 
d'une transaction de rechargement d'un porte-monnaie 
electronique) . 

Le but de 1' invention est que le serveur puisse 
detecter les defauts d' execution d'une ou plusieurs 
actions ou commandes, lies a une perte de messages 
entre le serveur et la carte a puce ou a des defauts 
d' execution d' actions dans la carte, lesdits messages 
ayant ete transmis a la carte eventuellement pendant 
une transaction en cours, ceci afin d'en informer le 
serveur pour que ce dernier determine quelles sent les 
dernieres actions ou commandes non executees par la 
carte. 

Selon une procedure pre-etablie en fonction de la 
ou des actions non mises en oeuvre, le serveur pourra 
par exemple renvoyer le message contenant la dite ou 
les dites actions et permettre leur execution. 
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A cette fin, 1' invention a particulierement pour 
obiet un precede de controle de 1'execution d'une 
oo^et ^ serveur vers une 

demande d' actions transmise par un serveu 
demanae ladit e carte comportant un 

carte via un terminal, lactone 

carte v . - ce qu'il comporte 

compteur d' actions, caracterise en ce q 

Ips etapes suivantes : 

les ew P serveur d'un message 

a) a 1' emission par le serve 
— une demande -p-t un. ou P^eurs 
actions a mettre en oeuvre par la carte, 
stocke le nombre n d'action de la demande; 

M t la reception du message, la carte execute 
successivement la cu les actions de la 
incremental son compteur d-actions entre ^ 
.ctions .1 1'action s'est bien executee et en -'-ant 
cette action et les actions successive* s. I'act.on 
s-est pas bien execute sans incrtmenter son compteur. 

o) on compare la variation entre la valeur dans 
la carte et cell, stockee dans le serveur et on 
aetermine que les x dernieres actions (commanded ne 
2 „ so n r pas executes si le r.sultat de la compara.son 

^^c^t^u compteur d-action correspond au 

nombre d' actions correctement executees. 

L e nombre x est e,al a 0 si toutes les actions sent 
25 correctement Sxecutees, ce nombre X peut done varier 
25 co " cl - . „ +-ont- es les actions ont 

de 1 a n si la derniere ou toutes xes 

^tur comparer la variation entre la valeur dans la 
carte et celle stockee dans le serveur, la carte 

^ i a valeur courante de son compteur 
-5 n transmet au serveur la vaieur 

avant et apres execution de la commande dictions, 
avant et apt t la va leur dans la 

Pour comparer la variation entre la 
carte et celle stockee dans le serveur, la carte 
carte e var . ia tion de son compteur suite 

calcule la valeur de la variation 



a 1' execution de la commande d' actions et la transmet 
au serveur. 

Selon une autre caracteristique, tout echange de la 
valeur du compteur d' actions de la carte est effectue 
sy sterna tiquement de maniere securise. 

A cette fin, la derniere valeur du compteur 
d' actions jde la carte est transmise avec un 
cryptogr amine dont le calcul implique la dite derniere 
valeur. 

Selon une autre caracteristique la derniere valeur 
courante du compteur d' actions de la carte est 
transmise au serveur en temps reel, c'est-a-dire 
pendant la transaction en cours. 

Selon un exemple la valeur pourra etre transmise au 
moyen du message d' acquirement de la transaction en 

cours dans la carte. 

Selon une autre caracteristique la valeur du 
compteur d' actions de la carte est transmise au serveur 
en temps d if fere. 

Selon un exemple la valeur du compteur d' actions 
pourra etre transmise au moyen d'un message d'une 
nouvelle demande de transaction par la carte par le 
serveur . 

Selon un autre exemple la valeur du compteur 
d' actions de la carte est transmise au moyen d'un 
message d' information emis pour la carte au serveur. 

L' invention a egalement pour objet une carte pour 
mettre en oeuvre le procede precite comportant un 
compteur et des moyens de gestion de ce compteur, 
caracterisee en ce que lesdits moyens de gestion -sont 
aptes a incrementer ledit compteur d' actions -entre 
chaque action si 1' action s'est bien executees et a ne 
pas 1' incrementer pour cette action ni pour les actions 
suivantes si cette action n'a pas ete executee. 
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D'autres caracteristiques et avantages de la 
presente invention apparaltront a la lecture de la 
description ci-apris donnee a titre d'exemple non 
5 limitatif et en regard des dessins sur lesquels : 

- la figure 1, illustre des echanges de messages 
entre serveur et carte a puce selon 1' invention, 

- la figure 2, illustre de maniere detaillee des 
echanges de messages entre serveur et carte a puce dans 

10 le cas d'une perte de message, 

- la figure 3, illustre un autre cas de perte de 

message. 

On entend par demande d' actions, un message 
15 comportant un jeu de n commandes, n pouvant bien 

entendu etre egal a 1. 

On pourra se reporter pour mieux comprendre la 

suite au schema de la figure 1. 

Dans toute la suite, on a pris comme exemple le cas 
20 ou le serveur 2 profite d'une transaction en cours dans 
une carte 1 pour lui envoyer une demande comportant une 
ou plusieurs actions que la carte devra executer. 

Bien entendu dans ce cas une demande d' action sera 
emise avec la reponse a la transaction en cours si 
25 ladite transaction necessite une reponse. Si ce n'est 
pas le cas, cree une reponse contenant uniquement la 
demande d'actions. Le terminal qui est en communication 
avec le serveur recoit le message correspondant a cette 
reponse, epure ce message de son enveloppe pour 
30 transmettre les actions a la carte. 

Une demande d'actions peut comporter plusieurs 
actions a entreprendre par la carte, c'est-a-dire comme 
precise au debut de . la description, un Deu de 
n commandes. 



A titre d' exemple une demande d' actions pourra etre 
une demande de changement d'un ou plusieurs parametres 
dans un programme duplication ou, le chargement d'une 
nouvelle application ou, le chargement d' unites de 
valeur. 

Le changement d'un parametre correspond a une 
action pour la carte qui est une operation d'effacement 
et ecriture a une adresse predeterminee . 

Le changement de plusieurs parametres correspond a 
autant d'operations d'effacement et ecriture^ a des 
adresse distinctes que de parametres et par consequent 
a autant d' actions a entreprendre qu'il y a de 

parametres a changer. 

On va maintenant detainer ce qui se passe cote 

carte et cote serveur. 
Cote carte : 

La carte 1 incremente apres chaque action 
correctement effectuee, le compteur d' actions CA des 
qu'elle recoit du serveur une ou plusieurs actions a 
entreprendre et qu'elle a pu mener a bien 1'execution 
de chacune de ces actions. 

La valeur du compteur est remontee vers le serveur 
par exemple chaque fois que la carte envoie un message 
au serveur (message 3 ou message 4 sur la figure 1) . 

La valeur du compteur peut etre remontee vers le 
serveur 2 essentiel lenient lors des actions suivantes : 

- lorsqu'il y a un acquirement de transaction (si 
durant une transaction un message d' acquirement est 
remonte au serveur on peut mettre dans cet acquirement 
la valeur du compteur d'actions), (exemple : 
message 3) , 

-lorsqu'il y a une demande de transaction ou 
d'authentification de la carte vers le serveur, 
(exemple : message 4), 
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- dans le cas de cartes bancaires ou de porte- 
monnaie electronique : 

- on stocke dans chaque terminal 3 toute 

transaction passee, 

- la transaction stockee est remontee au serveur 
pour que le serveur puisse enclencher le processus de 
paiement du marchand aupres duquel a eu lieu la 
transaction, le compteur d'actions CA peut etre remonte 
avec cette transaction. 

Ainsi, la valeur du contenu du compteur dictions 
est tou jours remontee au serveur soit en temps reel 
lorsque cela est fait lors d'un acquirement ou en 
temps differe lors d'une nouvelle demande de 
transaction ou lors d'une remontee d'un stockage de 
15 transactions. 

Cote serveur : 

Pour chaque carte contenant une application qui lui 
est dediee ayant une demande d'actions en cours, le 

serveur doit stocker : 

- le numero d' identification de 1 ' application, 

- la valeur courante du compteur d'actions, 

- la liste des actions en cours pour cette carte. 
Ainsi, le serveur auquel appartient une application 

placee dans une carte a puce multi-applicative, peut 
lors de n'importe quelle transaction demandee par la 
carte, commander une action telle qu'un rechargement 
d' unites, ou qu'un chargement d'un programme ou qu'un 
chargement de nouveaux parametres pour un programme 
residant dans la carte. 

Le serveur peut ainsi envoyer des actions a la 
carte par un mecanisme de script non interpretable par 
le terminal 3, qui se trouve entre le serveur et la 
carte pour assurer la communication. Le terminal 3 
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transmet le ou les messages re?us dans le script a la 
carte de maniere transparente . 

On va maintenant detailler 1' ensemble des 
traitements dans le cas ou la remontee du contenu du 
compteur d' actions se fait en temps reel et dans le cas 
ou tout se passe bien, c'est-a-dire dans le cas ou il 
n'y a pas de perte de message et ou l'execution par la 
carte s'est bien deroulee. 

On pourra se reporter au mode de realisation 
particulier illustre par le schema de la figure 1 pour 
mieux comprendre. 

-A 1' instant dti le porteur demande via son 
terminal 3 une transaction ( un paiement ou une autre 
transaction): message 1. 

- La carte prepare la transaction et un 
cryptogramme, c'est-a-dire les donnees 
d' authentication, designees par la suite par MAC et 
transmet au terminal. 

Associe a cette transaction, 1 ' application bancaire 
joint la valeur actuelle CA de son compteur d' actions 
securise par le cryptogramme. 

- Le terminal remonte la transaction au serveur 

bancaire. 

De f aeon pratique, la carte envoie un message de 
demande de transaction contenant les donnees MAC1 ainsi 
que la valeur du compteur d' action CA, et 
1' identification de la transaction demandee. 

- Le serveur verifie les donnees d'authentif ication 
de la carte MAC1 et traite la transaction. Le serveur 
peut a ce moment effectuer une action dans 
1' application de la carte. 

Selon un exemple particulier, il peut s'agir d'un 
chargement de parametre monetaire dans la carte, mais 
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comroe cela a ete dit, d'autres actions du type 
rechargement d'un porte-monnaie electronique sont 
egalement possibles. 

- Pour cela, le serveur va preparer une ou 
plusieurs commandes de chargement de pararoetres 
contenues dans un champ d' information denomme ci-apres 
script 1, et les donnees d' authentif ication securitaire 
MAC2 . 

- La demande d' action est envoyee par un message 2 
qui peut contenir la reponse a la transaction en cours 
si une telle reponse est prevue pour 1 ' application 
concernee . 

Au moment de 1' envoi du script 1 a la carte, le 
serveur stocke dans une base de donnee ce script 1, en 
15 y associant les donnees relatives a la carte, ainsi que 
la valeur courante CA du compteur d' actions de la carte 
(remontee de la carte vers le serveur durant la demande 
de transaction) . Ces informations vont permettre 
d'effectuer la synchronisation serveur-carte. 
20 _La carte qui recoit les commandes une a une du 

script 1, verifie le cryptogramme MAC2 , et effectue de 
maniere atomique (c'est-a-dire en une fois et de 
maniere indivisible) action par action de la liste du 
script 1 et incremente le contenu CA du compteur apres 
25 chaque action si celle-ci s'est bien deroulee. 

Lorsqu'une action s'est mal deroulee, le compteur 
d' action n'est pas incremente et les autres actions ne 
sont pas acceptees. 

- Afin de remonter au serveur la nouvelle valeur 
30 CA' du compteur d' actions CA de la carte, plusieurs 
schemas sont possibles : 

- remontee lors d'un message d' acquittement de la 
transaction en cours c'est-a-dire en temps reel, 
(correspond au message 3 de la transaction en cours) ; 
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- remontee de la valeur du CA' durant la 
prochaine transaction, (correspond au message 4 se 
produisant a 1' instant dtj); 

- a n'importe quel moment c'est a dire lorsque la 
5 carte envoie des informations au serveur. 

- Dans le cas de 1' exemple deer it, la carte renvoie 
un acquittement securise au serveur incluant le contenu 
CA' en temps reel. Celui-ci peut alors comparer la 
valeur retournee par 1 ' acquittement avec la valeur 
10 stockee dans sa base. 

Si la valeur CA' = CA+n, n etant le nombres 
d' actions du script 1, ceci prouve que le script 1 
s'est deroule correctement dans la carte. Le serveur 
peut alors ef facer ce script dans la base de donnees. 

15 

On va maintenant decrire en relation avec la 
figure 2, en reprenant le meme exemple, ce qui se passe 
lorsque se produit une coupure ou une perte du message 
de demande d' actions (message 2) . 
20 Dans ce cas de figure, la commande script 1 n'est 

pas arrivee dans la carte. Le serveur va devoir se 
resynchroniser. Le serveur est informe de cette 
situation car selon cet exemple il n'a pas recu 
d' acquittement . 

25 Dans les cas ou le serveur n' attend pas 

d' acquittement, il est informe lorsqu'il recoit la 
derniere valeur du compteur d' action de la carte c'est 
a dire par exemple lors de la prochaine transaction. 

En effet, durant 1' authentif ication de la carte par 

30 le serveur (verification MAC1) , le serveur identif ie 
que cette carte n'a pas recu le script 1 (ou que le 
script 1 n'a pas ete effectue correctement dans la 
carte) grace a la valeur CA' du compteur d' actions qui 
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est remontee au serveur et comparee a la valeur CA 
stockee dans le serveur. 

Si CA' est inferieur a CA et non egal, cela veut 
dire que la derniere ou les dernieres actions n'ont pas 
5 ete effectuees correctement . 

Dans ce cas le serveur remet a jour sa base de 
donn.es DB, en effacant la valeur CA pour mettre la 
valeur CA' . Le serveur est a nouveau synchros se et 
peut relancer la ou les dernieres actions non executees 

in par la carte. . 

On va raaintenant decrire en relation avec la 

figure 3, en reprenant toujours le meme exemple, ce qui 

se passe lorsque se produit une coupure lors du message 

d'acquittement. 

ce cas ne peut etre envisage que dans le cas ou un 
Mss . ge d- acquirement est prevu par 1 - application 
Mais le probleme peut se produire lorsque la 

r e»ontee du compteur d- actions est effectuSe au moment 
d-une demande d'une nouvelle transaction, ou de 1'envoi 
20 d'un message d' information. 

Dans ce cas de figure, lors de la nouvelle demande 
de transaction, la valeur courante du compteur 

-i- m' = CA+n est remontee. 

d' actions de la carte CA «-^» 

Le serveur compare cette valeur CA' a sa dernxere 
25 valeur stockee, c'est-a-dire CA. «e CA' = CA + n, le 
serveur sait que les n dernieres actions ont bxen ete 
m enees, 11 stocke la nouvelle valeur du coxnpteur 
I actilns, c'est-a-dire CA + n pour £tre synchronise avec 
la carte. 



13 



REVENDICATIONS 



1. Procede de contrdle de 1' execution d'une demande 
d' actions transmise par un serveur vers une carte via 
un terminal, ladite carte comportant un compteur 
d'actions, caracterise en ce qu'il comporte les etapes 

5 suivantes : 

a) a 1' emission par le serveur d'un message 
comportant une demande comprenant une ou plusieurs 
actions a mettre en oeuvre par la carte, le * serveur 
stocke le nombre n d' action de la demande; 

10 D) a la reception du message, la carte execute 

successivement la ou les actions de la demande en 
incrementant son compteur d'actions entre chaque 
actions si 1' action s'est bien executee et en refusant 
cette action et les actions successives si 1' action ne 

15 s'est pas bien executee sans incrementer son compteur. 

c) on compare la variation entre la valeur dans 

la carte et celle stockee dans le serveur et on 
determine que les x dernieres actions (commandes) ne 
sont pas executees si le resultat de la comparaison 

20 presente un ecart de x. 

2. Procede selon la revendication 1, caracterise en 
ce que pour comparer la variation entre la valeur dans 
la carte et celle stockee dans le serveur, la carte 

25 transmet au serveur la valeur courante de son compteur 
avant et apres execution de la commande d'actions. 

3. Procede selon la revendication 1, caracterisee 
en ce que pour comparer la variation entre la valeur 

30 dans la carte et celle stockee dans le serveur, la 
carte calcule la valeur de la variation de son compteur 
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10 



15 



20 



25 



suite a 1'execution de la co^ande d'actions et la 

transmet au serveur. 

w„«o ries revendications 2 ou 3 , 
4 Procede selon l'une des rev 

caract'erise en ce gue la carte transit ledites valeurs 
sous forme securisee. 

5 . Proc , a6 d-eCange de .essage selon^ - 

revendication L ^J^t ™ise en temps 

^n W ntPur d'actions de la carte 

reel! Jest-a-dire pendant la transaction en cours. 

.. P^a d'eOange de messages - 

r evendic.tion ». ^^^/^traTsmise au serveur 
compteur d'actions de la carte est en 
au moyen du message d< acquirement de la transa 
cours dans la carte. 

7 . proc.de d'ec h ange de messages selon la 

revendication 1. -^^J"^ transmise en temps 
compteur d'actions de la carte 

differe. 

ProCd, d-eOange de messages ^ la 
indication ^TcZe est tratsmise au serveur 

transaction par la carte pour le serveur. 

Precede d'echange de messages selon la 

en ce que la vaieur ^ 
indication 7, carac J^.. au moye n 

compteur d'actxons de la carte ^ 

d'un message d' information emis par 
serveur - 
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10. Carte pour mettre en oeuvre le procede selon 
l'une des revendications precedentes comportant un 
compteur et des rooyens de gestion de ce compteur, 
caracterisee en ce que lesdits moyens de gestion sont 
aptes a incrementer ledit compteur d' actions entre 
chaque action si 1' action s'est bien executees et a ne 
pas 1' incrementer pour cette action ni pour les actions 
suivantes si cette action n'a pas ete executee. 
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